Date: Thu, 29 Apr 93 04:30:10 PDT From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V93 #112 To: tcp-group-digest TCP-Group Digest Thu, 29 Apr 93 Volume 93 : Issue 112 Today's Topics: Thoughts about alloc, bugs and RSPF. (3 msgs) Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Wed, 28 Apr 93 10:12:26 CDT From: andyw@aspen.cray.com (Andy Warner) Subject: Thoughts about alloc, bugs and RSPF. To: tcp-group@ucsd.edu (TCP Group) Mike wrote: > [...] > The central problem of RSPF, about which there was an extensive series > of messages some months ago involving me, Fred Goldtein (goldstein@ > carafe.tay2.enet.dec.com), and Anders Klemets (klemets@scis.se), is > that NOS provides no opportunity to test a route without using it. It > is not desirable that routes which are in the process of being tested > by RSPF be used for anything else. NOS provides no method by which to > [...] An idea occured to me while reading this; would it be possible for RSPF function more as an autonomous process and source route any tests it used ? If it judges the route reliable, then it can update the routing table. I've not thought out any of the details so this probably woudn't work for many other reasons, but at least its a straightforward way of RSPF having "private" routes that its exploring.. I've never really understood why RSPF needs to know so much about low level stuff like ARP, but then again whenever I think about RSPF for too long my head hurts..... -- andyw. N0REN/G1XRL andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835 ------------------------------ Date: Wed, 28 Apr 93 10:12:26 CDT From: andyw@aspen.cray.com (Andy Warner) Subject: Thoughts about alloc, bugs and RSPF. To: tcp-group@ucsd.edu (TCP Group) Mike wrote: > [...] > The central problem of RSPF, about which there was an extensive series > of messages some months ago involving me, Fred Goldtein (goldstein@ > carafe.tay2.enet.dec.com), and Anders Klemets (klemets@scis.se), is > that NOS provides no opportunity to test a route without using it. It > is not desirable that routes which are in the process of being tested > by RSPF be used for anything else. NOS provides no method by which to > [...] An idea occured to me while reading this; would it be possible for RSPF function more as an autonomous process and source route any tests it used ? If it judges the route reliable, then it can update the routing table. I've not thought out any of the details so this probably woudn't work for many other reasons, but at least its a straightforward way of RSPF having "private" routes that its exploring.. I've never really understood why RSPF needs to know so much about low level stuff like ARP, but then again whenever I think about RSPF for too long my head hurts..... -- andyw. N0REN/G1XRL andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835 ------------------------------ Date: Wed, 28 Apr 93 10:12:26 CDT From: andyw@aspen.cray.com (Andy Warner) Subject: Thoughts about alloc, bugs and RSPF. To: tcp-group@ucsd.edu (TCP Group) Mike wrote: > [...] > The central problem of RSPF, about which there was an extensive series > of messages some months ago involving me, Fred Goldtein (goldstein@ > carafe.tay2.enet.dec.com), and Anders Klemets (klemets@scis.se), is > that NOS provides no opportunity to test a route without using it. It > is not desirable that routes which are in the process of being tested > by RSPF be used for anything else. NOS provides no method by which to > [...] An idea occured to me while reading this; would it be possible for RSPF function more as an autonomous process and source route any tests it used ? If it judges the route reliable, then it can update the routing table. I've not thought out any of the details so this probably woudn't work for many other reasons, but at least its a straightforward way of RSPF having "private" routes that its exploring.. I've never really understood why RSPF needs to know so much about low level stuff like ARP, but then again whenever I think about RSPF for too long my head hurts..... -- andyw. N0REN/G1XRL andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835 ------------------------------ End of TCP-Group Digest V93 #112 ****************************** ******************************